The present invention relates to performing backups, and more specifically, this invention relates to creating a point in time copy of a file using a block level of granularity.
During a backup of data, applications must prevent the data from being updated. If the data is updated during the backup, then it may not be possible to obtain a consistent backup. The length of time updates to the data must be prevented for may depend on an amount of the data being backed-up. Thus, for large quantities of data, applications may not be able to process updates to the data for an extended period of time.
Today, on count key data (CKD) devices, point in time copy techniques, such as Concurrent Copy or FlashCopy, are used to take consistent point in time backups of mainframe data. The use of a point in time copy technique may essentially eliminate the amount of time a data set is unavailable to users and applications. However, due to the mechanism by which such point in time copy techniques work, large amounts of drive space may be necessary to perform such backups.
When backing up Unix files, an administrator may create backups of files from a file system clone. Cloning a file system is also a point in time copy technique, but it is managed by software rather than a storage subsystem. File system cloning may reduce the time a file is unavailable for updates, just as hardware based point in time copy techniques, but it is a two-step process. Further, file system cloning does not allow performance of backup, recovery, or migration at file-level granularity.
Additionally, users may prefer relying on fewer products for disaster recovery, with file level granularity and policy-based automation in order to meet better RPO (Recovery Point Objective) and lower RTO (Recovery Time Objective).